Telecommunications system

ABSTRACT

A telecommunications system comprises a public network and one or more private networks each comprising a plurality of private exchanges (PBX&#39;s) coupled to the public network. Signal mapping from PBX to public format and inverse mapping from public to PBX format provides transparent signalling of PBX calls across the public network. This avoids the use of dedicated private lines for the private network traffic.

This invention relates to telecommunications, e.g. telephone systems andin particular to systems incorporating one or more private network.

BACKGROUND OF THE INVENTION

A conventional telecommunications private network comprises a number ofprivate exchanges or switches (PBX's) interconnected via privatetelephone lines and each of which serves a number of telephone or userterminals. The PBX's of the private system are interconnected by privateleased lines which are installed by the appropriate telephone servicesupplier. Call routing and call handling within the private network arecontrolled via the PBX's.

In addition to a basic telephony service (POTS) a private network isgenerally required to provide additional features such as callforwarding, call transfer, ring-back when free and conference calls.These features are not in general provided on a public network as theyare specific requirements of business rather than domestic subscribers.

A further service that is finding increasing usage is that of providinga direct dialling facility to telephone extensions attached to a PBX.For example the CENTREX system provides such a service.

The provision of private leased lines represents a significant capitalinvestment by the telephone service supplier. Furthermore these leasedlines represent an underused asset as they are in significant use, foronly a part, typically about one third, of the twenty four hour cycle.However, during their idle period, these lines are not available tocarry telephone traffic, e.g. to reduce an overload, for subscribersother than the private user to whom the lines have been leased.Expansion of the network is also difficult, as new dedicated lines haveto be provided for new business subscribers.

OBJECT OF THE INVENTION

An object of the invention is to minimize or to overcome the abovedisadvantage.

It is a further object of the invention to provide a system in whichcalls between PBX's are routed via a public network.

It is a further object of the invention to provide a system that isfully compatible with the above mentioned direct dialling facility.

SUMMARY OF THE INVENTION

According to the invention there is provided a telecommunications systemincorporating a public network and one or more private networks, eachsaid private network having a plurality of nodes between whichcommunication is, in use, performed via the public network, and whereinthe public network has means for providing a transparent communicationspath between the nodes of each said private network.

According to the invention there is further provided atelecommunications system incorporating a public network, and one ormore private networks each comprising a plurality of private exchanges(PBX's) and between which communication is, in use, performed via thepublic network, the system having means for mapping call signallinginformation from a said private network to the public network andinverse mapping call signalling information from the public network tothat private network whereby to provide a transparent communicationspath via the public network between the private exchanges of each saidprivate network.

According to another aspect of the invention there is provided a methodof providing telecommunications signalling between a plurality of nodesor private exchanges (PBX's) constituting a private network, thesignalling being performed via a public network, the method includingmapping signalling information associated with each private networkmessage to corresponding signalling information associated with thepublic network, routing the message across the public network, andinverse mapping the signalling information associated with the publicnetwork to the signalling information associated with the privatenetwork whereby to provide a transparent communications path between theexchanges of the private network.

By providing a transparent signalling path between the nodes of theprivate network, all the call handling features of the private networkare available to users of that network even though these features maynot be provided by the public network itself. The private network callsare routed via the public network rather than via conventional dedicatedleased lines or `tie lines` making more efficient use of the publicnetwork capacity. The public network in effect provides virtual tie lineconnections between the PBX's of the private network.

The technique is of particular application to system employing a digitedprivate network signalling system e.g. the DPNSS (RTM) private networkcommon channel signalling protocol, but it will be appreciated that thetechnique is in no way limited to that particular signalling protocol.The technique is also applicable e.g. to the QSIG European PBXsignalling standard. The public network also has a common channelsignalling capability and may for example employ the CCS7 (commonchannel signalling system) protocol such as the DMS (RTM) digitalmultiplex system, although it will again be appreciated that theinvention is not limited to this particular public switch. The DPNSSprotocol is a common channel signalling system, primarily for use withinprivate networks, to provide telephony, data services, and a range ofsupplementary services. DPNSS contains circuit related (`Real Call`)procedures, and circuit independent (`Virtual Call`) procedures toprovide these services. In order to provide DPNSS transparency over CCS7we support equivalent mechanisms. DPNSS `Real` calls are progressedacross CCS7 using the integrated Signalling Digital Network User Part(ISUO), and DPNSS `Virtual` calls are progressed using the CCS7Transaction Sub-Layer (TSL) and the Signalling Connection Control Part(SCCP).

We achieve this transparent carriage by reconstituting the DPNSSinformation at the CCS7 end nodes so that full DPNSS functionality isprovided. In order to provide the required functionality, the systemoperates according to the following principles.

Any information that can be mapped uniquely between DPNSS and CCS7messages, and therefore can be reconstituted completely, is interworkedat a CCS7 end node. I.e. this information will not need to be carriedtransparently within the CCS7 message as well as being mapped. Any DPNSSinformation that can not be mapped uniquely, but can be used to setappropriate CCS7 parameters is utilised, but is also carriedtransparently within the CCS7 message. Any DPNSS information that has norelevance at all to the CCS7 message is carried transparently within theCCS7 message.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will now be described with reference tothe accompanying drawings in which:

FIG. 1 is a schematic design of a telecommunications system in whichprivate network traffic is carried via a public network;

FIG. 2 illustrates the manner in which calls are routed across thenetwork of FIG. 1;

FIGS. 3 and 4 illustrate respectively the high level mapping of messageand parameter information in the system of FIG. 1;

FIG. 5 illustrates the call set-up process;

FIG. 6 illustrates the pre-conversation phase of a call;

FIG. 7 illustrates the speech phase of a call;

FIGS. 8 and 9 illustrate respectively forward and backward release of acall;

FIG. 10 illustrates the support structure of a virtual call in thesystem of FIG. 1;

FIG. 11 illustrates the high level mapping of virtual messages;

FIG. 12 illustrates the transmit mechanism of virtual calls;

FIG. 13 illustrates the handling of additional messages in a virtualcall;

FIG. 14 illustrates premature release of a virtual call; and

FIG. 15 illustrates processing of a virtual call at a terminating node.

DESCRIPTION OF PREFERRED EMBODIMENT

In the following description of the preferred embodiment, particularreference is made to the DPNSS private signalling system and to the DMSpublic switching system. It will be appreciated that the description ofthe invention with those two systems is given by way of example only andthat exploitation of the invention is in no way limited to the use ofboth or either of these particular systems.

Referring to FIG. 1, the public network incorporates a number of nodes11 each of which may comprise e.g. a switching office or a signaltransfer point. A switching office is a node which is host to a numberof system users and acts as a source and sink of user generatedmessages. A signal transfer point is a node which tandems messagesbetween switching offices. Selected nodes of the public network maycomprise e.g. gateway switches 100 to permit communication with othernetworks.

The public network is accessed by a plurality of subscribers some ofwhich comprise single telephones 12 and others of which comprise aplurality of private exchanges (PBX's) 14, the private exchanges formingthe nodes of a private network.

Signalling within the system of FIG. 1 is performed via a common channelsignalling (CCS) protocol. This technique partitions the control of acall from the voice path so that inter-office communication is based ona request data exchange capability. This contrasts with conventionalper-trunk signalling (PTS) in which a call's control signal and voicesignals are multiplexed on to the same trunk.

In the system of FIG. 1, calls between PBX's are routed across thepublic network using quasi-associated signalling, this technique beingillustrated schematically in FIG. 2. Messages relating to a particularsignalling relation between a pair of PBX's, 14a, 14b are conveyed overtwo or more linksets in tandem passing through one or more nodes 11a,11b of the public network. For calls between PBX's, the public systemnodes function as signalling transfer points to provide physicalcommunication between the PBX's 14a, 14b, to provide in effect a virtualcommunications path directly between the PBX's of the private network.

To achieve transparency of a communications path between PBX's, weprovide mapping of both message information and parameter informationbetween the private network DPNSS information and the integratedsignalling digital network user part (ISUP) associated with the publicnetwork. The high level mapping of message and parameter information areillustrated respectively in FIGS. 3 and 4 of the drawings.

The private network calls routed via the public network are of twotypes; real calls and virtual calls. A real call requires establishmentof a connection between two parties and can carry speech or data. Avirtual call is a mechanism for communicating information between nodeswhen a physical circuit connection is not required, e.g. when making acall-back when free request.

Real Calls

For `Real` calls the signalling messages and related procedures aresectioned into the following call phases:

Successful Call Set-up Phase

This phase begins with an initial address message, and ends with thereceipt of an address complete message, indicating all digits have beensuccessfully received at the terminating end.

Unsuccessful Call Set-up Phase

This phase begins if any unsuccessful backward signal is received inresponse to an initial address message. The action taken on receipt ofsuch a signal may be to reattempt the call on another circuit, or toenter the Release Phase, and clear the call attempt.

Pre-Conversation Phase

This phase begins with the receipt of the address complete message, andends when an answer message is received.

Speech Phase

This phase begins with the receipt of an answer message, and continuesuntil the call is released.

Release Phase

This may be initiated from any other phase during the call. The callwill be released, and trunks will be passed to the Idle Phase

Idle Phase

Interaction between trunk maintenance and call processing will occur inthis phase.

For each phase a description of the mapping required is given below.

In the successful call set-up phase the following procedures occur. Thefirst message to arrive at the originating public system node is a DPNSSISRM(C). The ISRM(C) message is the first message to be sent in the callset-up phase, it is only applicable in this phase, and can only pass inthe forward direction. This message contains all the selectioninformation needed to progress the call, and may also containinformation relating to supplementary service requests. All thisinformation is carried in the DPNSS Selection Block, which may be up to44 octets in length.

When the DPNSS ISRM(C) message is received at the public system node,the calling line category (CLC) is examined for compatibility with theoutgoing route and the service indicator field is screened to determinewhether or not the call is allowed to continue. The procedure isillustrated in FIG. 5 of the drawings.

Unsuccessful Call Set-up Phase

This phase is initiated in one of the following ways:

An internal DMS treatment is set. A DPNSS message is received with aninvalid service indicator code. The call will be handled as specified inreference 3.

An ISUP Release Message (REL) is received.

If the failure occurred in the terminating DPNSS network the ISU P RELmessage contains DPNSS Indication Block information, which is passed toDPNSS, and a DPNSS CRM is generated (see FIG. 12 on page 38). If thefailure occurred in the DMS ISUP network the ISUP REL message is mappedto a DPNSS CRM.

An ISUP Blocking Message (BLO)/ Reset Circuit Message (RSC)/ or anUnrecognised Message is received, from the DMS ISUP network. The DMSnetwork isolates the related circuit and repeats the call attempt onanother circuit.

Pre-Conversation Phase

This phase begins with the receipt of a backward DPNSS NumberAcknowledge Message, and generally ends with the receipt of an DPNSSCall Connected Message (CCM).

On receipt of the DPNSS NAM message the DMS generates an ISUP ACM, fromthe information received within the DPNSS Indication block, and frominformation held at the DMS. The DPNSS SM message is always accepted, as64 K bit/s clear capability is always assumed. On receipt it is mappedinto an ISUP PAM message and sent over the preceding link.

Any other DPNSS message received in the backward direction, other thanCCM or unrecognised or invalid link-by-link messages are mapped into anISUP PAM and sent over the preceding link. In the case of EEM(I)'s andEEM(C) all the information will be collected at the node before beingmapped into an ISUP PAM. This will also be true for LLM(I)s and LLM(C).

On receipt of a DPNSS CCM message, an ISUP ANM is generated and is sentover the ISUP link, the procedure being illustrated in FIG. 6.

Call Duration (Speech) Phase

This phase, illustrated in FIG. 7, begins with the receipt of a backwardDPNSS CCM Acknowledge Message, and ends when release is initiated.

Release Phase

The Release Phase can be initiated from any other phase during the call.Release is activated on a link-by-link basis. On receipt of a DPNSS CRMmessage, an ISUP REL message is generated and sent over the ISUP link.Likewise, on receipt of an ISUP REL message, a DPNSS CRM is generated bythe DMS, and sent over the DPNSS link. The DPNSS indication blockinformation will be mapped into the ISUP REL message and passed to DPNSSrespectively.

In response to the CRM message, a DPNSS CIM is generated and sent overthe DPNSS link. In response to an ISUP REL message an ISUP RLC isgenerated and sent over the ISUP link.

FIGS. 8 and 9 illustrate the release procedure for forward directionrelease and backward direction release respectively.

Idle Phase

This phase begins when the RLC/CIM message appropriate to the circuitbeing idled is received.

The Virtual Call

The DPNSS `Virtual Call` is a mechanism for communicating informationbetween nodes, when a physical circuit is not required, for instancewhen registering and cancelling a Diversion supplementary service, orwhen making a Call Back When Free request. The equivalent functionalityis provided by the ANSI Transaction Sub-Layer (TSL) and the ANSISignalling Connection Control Part (SCCP). A limited portion of the ANSIComponent sub-layer is also supported to handle error conditions.

As a general principle the DPNSS `Virtual` call signalling messages andprocedures can be considered as the same as those for a `Real` call. TheDPNSS `Virtual` call can be considered as a `Query`/`Response` cycle,performed with the DPNSS ISRM and CRM messages respectively, this mapswell to the Transaction Sub-Layer (TSL) `Query`/`Response` transaction.The capability to pass on any DPNSS message received during a `Virtual`call is supported across the CCS7 network to ensure that the principleof DPNSS transparency can be followed if thus functionality is requiredat any time.

The structure used for the support of `Virtual` calls is shownschematically in FIG. 10. A new Transaction User (TR-User) is createdcalled `Signalling Transparency`. This application assigns transactionidentifiers (TRID) and encapsulate/extract the received DPNSS messagesto and from TSL-primitives. It utilises the TSL services to provide aconnection-oriented association between the two peer TR-Users at theoriginating and terminating CCS7 nodes. At the transport level the SCCPconnectionless service is used to route the TSL messages across the CCS7network.

FIG. 11 shows a high level mapping of DPNSS `Virtual` messages to andfrom TSL messages. Within the description any reference to the TSL QUERYmessage should be interpreted as QUERY with permission, and anyreference to the TSL CONVERSATION message should be interpreted asCONVERSATION with permission.

The DPNSS `Virtual` call, as mentioned previously, can be thought of asa single transaction. Within the following section the signallingmessages and procedures for such a transaction will be defined. Thespecific procedures relating to each of the three possible scenarios(`Transit`, `Gateway`, and `End` node capabilities) will be discussedseparately. This is illustrated schematically in FIG. 12. As for `Real`calls, the underlying principle in the transit case is to pass on anyinformation received at the CCS7 end nodes. A number of TSL messages areused between the originating and terminating nodes to convey the DPNSSinformation. A TSDL Query message is issued to begin a transaction, aTSL Conversation message is issued to allow a continuation of thetransaction, and a TSL Response message is issued to end thetransaction. TCAP protocol errors are reported via a Reject componentwithin a Response or Unidirectional message. Application errors arereported via a Return Error component within a Response orUnidirectional message.

On receipt of all the DPNSS Selection Block information (obtained froman ISRM(C) or a sequence of ISRM(I), SSRM(I)s ands SSRM(C)), the DMSnode attempts to assign a TSL Transaction Identifier (TRID) to identifythe transaction at the CCS7 originating node.

If successful, the DMS node generates a TSL QUERY message, frominformation within the DPNSS Selection Block, and information held atthe DMS. The DPNSS message(s) is carried transparently within the QUERYmessage. The message will be sent to the succeeding node, via the CCS7SCCP connectionless service. An association between the assigned TRIDand the DPNSS virtual channel identifier is maintained by the DMS forthe duration of the transaction, in order to route correctly any furthermessages.

If the attempt to assign a TRID is not successful, the DMS node willfail the call with a DPNSS CRM indicating `Congestion`.

At any DMS transit nodes the SCCP message received will be progressed asa normal connectionless SCCP message.

On receipt of a TSL QUERY request at the DMS terminating node, the QUERYmessage is validated, and the DMS node attempts to allocate a TRID.

If successful an `Empty` TSL CONVERSATION message, i.e. containing nouser data) is generated by the DMS and sent to the originating node toacknowledge the received message. This acknowledgement procedure must becarried out for the DPNSS transparency application, so that any furtherDPNSS messages received at the CCS7 originating node can be progressedover the CCS7 network, (i.e. the `terminating nodes` TRID is required atthe CCS7 originating node before any other message can be sent in theforward direction). Once the TSL QUERY message has been validated and aTRID assigned, the DPNSS message is extracted from the QUERY message,and processed as normal in order to determine the DPNSS outgoing route.A timer to supervise the outgoing DPNSS `virtual` call is started onsending the `virtual` ISRM message. An association between the CCS7terminating nodes TRID and the DPNSS virtual channel identifier ismaintained by the DMS node for the duration of the transaction, in orderto route correctly any further messages.

If the attempt to assign a TRID is unsuccessful, a return errorcomponent is generated by the DMS and sent within a Unidirectionalmessage to the originating node to terminate the attempted transaction.

Any further DPNSS messages received for the `Virtual` call are held atthe DMS until the TSL CONVERSATION message, providing the TRID of theCCS7 terminating node arrives. Once received any DPNSS messages beingheld at the DPM, other than CRM, are encapsulated in TSL CONVERSATIONmessages and sent over the CCS7 link as illustrated in FIG. 13.Messages, such as the EEM(I)s that have to be buffered at the DMS beforebeing sent over each link, can be collected together and sent within asingle TSL CONVERSATION message. The limit on the number of messagesbeing determined by the DPNSS Indication Block limit of 135 octets.

On receipt of any further TSL CONVERSATION messages from the CCS7terminating node, the DMS extracts the DPNSS message, processes it asnormal, and sends it over the preceding DPNSS link.

A DPNSS CRM message received in the forward direction indicates that theDPNSS `Virtual` call should be released, and hence is mapped to a TSLRESPONSE message to initiate the termination of the TSL transaction. ADPNSS CIM message is generated in response to the CRM, and sent over thepreceding DPNSS link. The TSL TRID is then released. This procedure isillustrated in FIG. 14 of the drawings.

On receipt of a TSL RESPONSE message, the DPNSS CRM message is extractedand sent, and the TSL TRID is released. If a TSL Response orunidirectional message is received containing a Reject or Return Errorcomponent, the DMS fails the `Virtual Call` with a DPNSS CRM. At any DMStransit nodes the SCCP message received is progressed as a normalconnectionless SCCP message.

At the DMS terminating node, any backward DPNSS message received for the`Virtual` call, other than CRM, is mapped into a TSL CONVERSATIONmessage and sent over the CCS7 link.

A DPNSS CRM message received in the backward direction indicates thatthe DPNSS `Virtual` call should be released, and hence is mapped to aTSL RESPONSE message to initiate the termination of the TSL transaction.A DPNSS CIM message is generated in response to the CRM, and sent overthe preceding DPNSS link as illustrated in FIG. 15.

On receipt of any TSL CONVERSATION message from the CCS7 originatingnode, the DMS extracts the DPNSS message, processes it as normal, andsends it over the succeeding DPNSS link. On receipt of a TSL RESPONSEmessage, the DPNSS CRM message is extracted and sent and the TSL TRID isreleased.

It will be appreciated that adaptation of the technique to telephonesystems other than those described above may be achieved by theprovision of suitable mapping and inverse mapping functions between thepublic and private systems.

We claim:
 1. A telecommunications system incorporating a public switchednetwork having a first signalling protocol, and a circuit switchedprivate network having a further signalling protocol and comprising aplurality of private exchanges (PBX's) or nodes between whichcommunication can be established via circuits set up between the privateexchanges in the public network, wherein telephone calls between saidprivate exchanges comprise real calls in which a voice circuit isestablished between private network terminals and virtual orconnectionless calls which carry signalling information without theestablishment of a voice circuit, and wherein both real and virtualcalls between said private exchanges are routed across the publicnetwork, the system having means for mapping call signalling informationfrom said further private network protocol to a corresponding equivalentpublic network message containing signalling information in said firstprotocol of the public network, means for inverse mapping callsignalling information from said first protocol of the public network tothat of the private network whereby to provide a transparentcommunications path via the public network between the private exchangesof said private network, and means for carrying transparently within afirst signalling protocol message across the public network privatenetwork signalling information in said further signalling protocol forwhich no equivalent message is available in the first signallingprotocol.
 2. A telecommunications system as claimed in claim 1, whereincalls routed across the public network between said private exchangesare provided with a signalling format in which signalling messagesbetween private exchanges are conveyed over two or more linksets intandem passing through one or more nodes of the public network.
 3. Atelecommunications system as claimed in claim 2, wherein said firstsignalling comprises a common channel signalling protocol.
 4. A methodof providing telecommunications signalling via a circuit switched publicnetwork having a first signalling protocol between a plurality of nodesor private exchanges (PBX's) a constituting a circuit switched privatenetwork having a further signalling protocol, wherein private networkcalls are set up by signalling between said private exchanges via thepublic network, wherein telephone calls between said private exchangescomprise real calls in which a voice circuit is established betweenprivate network terminals and virtual or connectionless calls whichcarry signalling information without the establishment of a voicecircuit, and wherein both real and virtual calls between said privateexchanges are routed across the public network, the method includingmapping signalling information in said further signalling protocol to acorresponding equivalent public network message containing signallinginformation in said first signalling protocol associated with the publicnetwork when such an equivalent message is available in the firstsignalling protocol, routing said corresponding public network messageacross the public network, and inverse mapping at a said privateexchange the signalling information in said first signalling protocolassociated with the public network in said public network message to thesignalling information in said further signalling protocol associatedwith the private network whereby to provide a transparent communicationspath between the exchanges of the private network, and wherein privatenetwork signalling information in said further signalling protocol forwhich no equivalent message is available in the first signallingprotocol is carried transparently within a first signalling protocolmessage across the public network.
 5. A method as claimed in claim 4,wherein calls routed across the public network between said privateexchanges are provided with a signalling format in which signallingmessages between private exchanges are conveyed over two or morelinksets in tandem passing through one or more nodes of the publicnetwork.